Thank you @simonhoss great to see this because it's implementing a missing feature in JetStream.

My initial thoughts are:

• We don't want to penalize applications which are not using JetStream but using the reply subject for other patterns of messaging,
• The feature really belongs to JetStream project,
• NatsMsg is a struct so we need to be careful about enlarging it,
• Have you considered calculating it on demand? (I'll also check with other client maintainers see how they're doing it)

Thanks for the feedback. When I started the implementation I didn't realize that there are two msg's in (NatsMsg and NatsJSMsg). With this new knowledge and your feedback, I was thinking about to implement it only in the NatsJSMsg with a lazy implementation. That means that the Seq and DateTime gets only calculated if someone wants to know it.

What do you think?

Brilliant! Is there a way we can retrieve the new properties on NatsJSMsg without storing them on NatsMsg? Because NatsMsg is a struct it means every message needs to be copied so we want to keep it as small as possible 😉

BTW @simonhoss please sign your commits

I added a new approach, which doesn't touch the NatsMsg and only calculates the Sequence and DateTimewhen someone really consumes it.

Also my commits are now verified for this project 😉

New version pushed. I think it should now parse both versions correct.

Also, Im not quite sure if struct makes sense for NatsJSMsgMetadata, but NatsJSMsg is also a struct, so I took the same.

Also @simonhoss please feel free to join https://slack.nats.io #dotnet channel if you haven't already done so. I'd love to see you there too 💯

Thanks a lot!